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ABSTRACT 

The Launch Decision Support System (LDSS) is 
software to be used by the NASA Test Director (NTD) in the 
firing room during countdown. This software is designed to 
assist the NTD with time management, that is, when to resume 
from a hold condition. This software will assist the NTD is 
making and evaluating alternate plans and will keep him 
advised of the existing situation. As such, the interface 
to this software must be designed to provide the maximum 
amount of information in the clearest fashion and in a 
timely manner. This research involves applying user 
interface guidelines to a mature prototype of LDSS and 
developing displays that will enable the users to easily and 
efficiently obtain information from the LDSS displays. This 
research also extends previous work on organizing and 
prioritizing human-computer interaction knowledge. 
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SUMMARY 

The Launch Decision Support System (LOSS) is being 
developed as an aid to the NASA Test Director (NTD) during 
countdown activities. This report presents suggested 
revisions of many LDSS displays. The revisions were 
developed by applying human-computer interaction guidelines 
to the original interface. Data collected from potential 
users was also considered in developing the revisions. This 
data was collected via a think aloud protocol, numerous 
interviews, and a questionnaire. This data verified that 
users found the color coding of the revisions sufficient, 
that they could correctly interpret information coded into 
one window rather than three, and that reducing the time 
labels was acceptable. The emphasis in developing the 
revisions was on presenting the information so that it could 
be interpreted quickly, easily and unambiguously by casual 
users in a critical, real-time environment. 

The task of applying Human-Computer Interaction 
knowledge is difficult because research done in this area is 
often difficult to translate into practical guidelines. A 
means of organizing human-computer interaction knowledge 
into a generic framework is discussed. However this method 
alone is not sufficient to be able to use HCI knowledge. 
Other problems still exist. For example, during the 
revision process many trade-offs were made when deciding 
which guidelines to apply. A method was used to prioritize 
guidelines by examining different characteristics of tasks 
and users. For various characteristics the criteria of 
primary importance are proposed. Using task and user 
characteristics of LDSS and applying this prioritizing 
method resulted in the following primary criteria: 
consistency, guidance, workload, and significance of code. 
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I. INTRODUCTION 

1.1 Organization of the Paper 

This paper documents the application of Human- 
Computer Interaction knowledge to the interface for the LDSS 
software for use in the KSC firing room. The first section 
discusses the role of the NASA Test Director (NTD) who is 
seen as the principle user of LDSS. The functionality of 
LDSS is explained in this section. Section II presents 
redesigned displays and discusses the rationale behind the 
redesign. Also included in Section II are the results of 
data collection On usage of the displays. A discussion of 
complexity measures in original and revised displays is also 
presented. Section III discusses how human factors 
knowledge can be organized and applied to interface designs. 
A method of addressing the trade offs involved in interface 
design is presented. Section IV presents Interface 
Guidelines for future firing room software. Additional 
suggestions are included for a proposed windows version of 
such software. Section V contains concluding remarks. 

1.2. The Role of the NTD 

The NASA Test Director functions as the 
coordinator of information during a launch countdown. He 
receives information from several diverse sources: firing 

room clocks located on the wall in front of him and to his 
left, procedural information in hard copy from the OMI 
(Operations and Maintenance Instructions) and status 
information received over the OIS (Operations Information 
System) . The current firing room clocks are universal time 
(UT) , local time(local), countdown time (shuttle), window 
remaining, post LOX drain back elapsed, APU hold time 
remaining, time to T-0, and hold time remaining. Specific 
information about each launch, such as projected time of 
lift-off, launch window end, etc., is contained in a launch 
document for that particular mission. He also has access to 
closed circuit television which is directed at operations 
occurring around the launch pad. One of the many 
responsibilities of the NTD is that of time management. That 
is, given that a hold has occurred in the countdown, The NTD 
must decide upon the time to resume the count so that lift 
off will not occur within a COLA or with little contingency 
time. In making decisions concerning time management, the 
NTD has to carry out some arithmetic operations and base his 
decision on those calculations plus his knowledge of 
specific launch information. In addition, he uses knowledge 
of approaches used in previous launches. 

The LDSS consists of several parts: the time 

management integrated display, the what-if capability, the 
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situation assessment capability, and anomoly management. 

The time management subsystem presents an integrated 
display. That is, all firing room clocks are duplicated on 
this display. Additionally, some clocks that perform 
arithmetic are displayed. The launch window is shown along 
with any COLAS (collision avoidance) . These represent 
periods in the launch window such that a lift-off during 
this period could results in a collision with another 
orbiting vehicle. Contingency times are shown in the launch 
window as these also affect resumption from a hold. The 
time management display (shown in figure 1) calculates the 
advisability of resumming from a hold and displays this 
information in its resume window. A now bar displays the 
current position in the countdown and a projected T-0 bar is 
consistently updated to reflect where lift off will occur. 
The LOX DB is the contingency time currently deemed to be 
the most constraining. 

1.3 The Need for Human-Computer Interaction Knowledge 

LDSS is designed to assist an NTD during 
countdown activities. Activities such as these are 
performed on the order of every two weeks. This 
includes simulations and actual launch activities. The 
NTDs alternate with one NTD and one ANTD assigned to 
every launch team. Therefore, these are casual users. 

The activity they perform, launching a manned shuttle, 
is a critical operation. The countdown activity is a 
cognitively demanding activity that must be carried out 
in a real-time situation. This means that any tools 
designed to assist the NTD and ANTD need to present the 
needed information in such a fashion that it can be 
easily comprehended and used. This project reports on 
a suggested redesign of the user interface for the 
LDSS. Accomplishing this redesign led to many tradeoff 
decisions. This study also proposes a method for 
prioritizing guidelines in order to make consistent 
decisions about trade-offs. 
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II. LDSS Revised Displays and Data Collection Results 


2.1 TMID Revised Display 

Figure 1 shows the original TMID screen and 
Figures 2,3 and 4 show the revised display. The largest 
change was using one "window" on the display for information 
concerning the launch window. The original display 
contained a launch window which showed COLAS, a resume 
window which showed the advisability of resuming from a 
hold, and a LOX drain back window which showed the LOX 
contingency time remaining. In addition, the display 
contained a "now bar" and a projected T-0 bar, to show where 
the countdown currently was and where this meant that T-0 
would occur. Interviews with members of the NTD staff 
indicated that there was confusion with using three 
different windows, especially the launch window and the 
resume window. Therefore, the display was reworked using 
only one window - the launch window - and incorporating the 
information about COLAS, contingency time and advisability 
of resumming in this window and elsewhere on the display. 

The revised display uses the stop light coloring coding on 
the launch window. Green indicates that the window is open 
at this point. Yelllow indicates contingency times and is 
seen prior to COLAS (indicated in red) and prior to the end 
of the launch window. The end of the launch window is 
labeled as such and nothing is displayed after this point. 
The "now bar" is coded to indicate the advisability of 
resumming at this point in time. Green indicates that 
resumption is safe (or that the countdown is not currently 
in a hold) . Yellow indicates that a resumption at this time 
would not have the full contingency time. Red indicates 
that resumming from a hold at this time would place T-0 in a 
COLA. There are two methods of finding out how long the 
period for resumming exists. One is by looking at the 
launch window to see the amount of green, yellow or red 
(also labeled) displayed below the projected T-0 bar. At 
the beginning of the T-20 hold this information would have 
to be obtained by scrolling the launch window. 

Additionally, this information is contained in a new clock 
"Time to No Start". This will provide exact times that 
indicate how long the current condition exists. 

The time labels were also changed. The original 
display labeled all times, universal time and countdown 
time. The revised display only labels significant times. 
That is, only the minutes in which a GLS event or a COLA or 
a contingency time appears will be labeled with the univeral 
and countdown time. Countdown times are only labeled for 
times prior to T-0. Positive countdown times make little 
sense for COLAS and contingency labels. The "now bar" 
always reflects the current time correct to the second. 
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Using a reduced amount of time labels will make those that 
are significant stand out and reduce the overall complexity 
of the display. More will be said about this in Section 
III. 

The original TMID screen contained a scroll bar on 
the left side of the display which was used to indicate 
which portion of the display was being viewed. The revised 
TMID screen had more room so that the scroll bar could be 
moved to the right hand side of the display in keeping with 
an OSF/Motif presentation. The scroll bar was designed so 
that it resembles that of OSF/Motif. Recommended movement 
with the display window should be via the scroll bar or by 
using the up arrows and page keys. Either motion results in 
the slider of the scroll bar being changed to relfect what 
portion of the display one is viewing. In a direct 
manipulation version, the user should also be able to 
position the slider to cause movement. 

Color coding on the revised TMID screen is 
consistent. Graphic information is color coded using the 
green (safe) , yellow (cautionary) , and red (warning) traffic 
light metaphor. However, the graphic data has also been 
labeled so that color coding is redundant and therefore, can 
be used by a visually impaired person. Text information 
uses cyan for labels and place holder values. White 
indicates information that needs to be input. Values in 
green are relevant; that is, data that has occurred. Yellow 
labels and values depict information concerning a hold. Red 
values are values that indicate a warning situation exists. 
One color change that was made to the original TMID screen 
is that recommendation of using cyan as the color for data 
that is not yet relevant. Previously non-relevant data had 
been displayed in white. White should be reserved for very 
important data. Data that is not yet relevant is not 
invalid, but merely serves as a placeholder. Therefore, 
using the same color as labels (cyan) is recommended for 
such data. In general, no more than four colors should be 
used for alphanumeric information. The revised TMID screen 
(and other screens in LDSS) use cyan, green, yellow and red. 
As red is used very sparingly and only in the case of 
warning situations, the use of the three colors to display 
text, plus the background color of black, closely adheres to 
this guideline. 

The clocks in the original TMID screen were 
rearranged and "chunked" together according to function. 

For example, time in hold and hold time remaining were 
located together. This reduces the complexity for the user 
by presenting a few chunks of information rather than a 
large number of information pieces. In addition, the clocks 
were arranged in order from top to bottom with those on the 
top being the highest priority. This arrangement was based 
on interviews with the NTD staff. This rearrangement 
allowed enough room on the display to include the maximum 
hold time remaining and the latest resume time. For time 
values that are not currently in use the recommendation is 
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to use a default value of HHMM/SS or DDD:HHMM/SS as a prompt 
to the user of the format of the clocks. This is due to the 
lack of room for labels on the clock values. A graphic 
depiction of where the projected T-0 falls in the launch 
window was also incorporated into the clock display. This 
was purposely designed NOT to look like a scroll bar as it 
CANNOT be manipulated and is used to quickly show the NTD 
how close to the end of the launch window, the projected T-0 
is . 

2.2 Finer grain TMID Screen 

Feedback from the users indicated that as T-0 
neared, the minute resolution on the TMID screen was too 
coarse to follow. A finer grain of time, namely a 10 second 
resolution, is recommended. Figure 5 presents this new 
display. The same format as the TMID screen is used. The 
time bars in the launch window now become 10 second bars so 
that one rectangular box per line is used. Time labels are 
indicated on whole minute entries. This display should be 
included in the menu and the user could select to view this 
display when a certain point in the countdown is reached. 

2.3 Overview Display 

Another new display that was developed during this 
period of time is the overview display. The concept is that 
this display would present the entire launch window picture 
to the NTD. The display, shown in Figure 6, could be 
derived from the mission parameters that are input prior to 
bringing up LDSS. The entire window is displayed with 
COLAs, COBT , and built-in holds at T-20 and T-09. This 
display could be used in a static fashion. That is, hard 
copies of it could be printed and used by the NTD to get an 
overall picture of the launch window. Figure 7 shows that 
the same display might also be used in a dynamic fashion 
with the addition of a now bar and a projected T-0 bar. 

2.4 Test Parameters Display 

Figures 8 and 9 present the original and revised 
Test Parameters display. The original display listed the 
built-in holds by time. Normally, searching would be done 
according to the time of the hold. Therefore, these columns 
were rearranged to facilitate that search. As LDSS 
currently is designed to function from T-20, only those 
built-in holds at T-20 and T-9 need to be displayed. The 
original display contained only the start and end time of 
the launch window (unlabeled) . The revised display contains 
the start, end and length of the launch window, COLAS, and 
COBT. In addition, the point of no recycle is now included 
on this display rather than on the TMID screen. 

This same display could be used for input about 
each specific mission. The input display looks very much 
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like the mission parameters display but contains information 
on how to input new values. The data fields are displayed 
in white, indicating that these fields are to be filled in 
by the user. The fields indicate the number of positions 
that are to be filled in and the format of that data. For 
example, a length field in countdown time format would look 
like HHMM/SS . A universal time format would be coded as 
DDD:HHMM/SS. In entering data, the user should not have to 
enter the fixed delimiters, e.g., : and /. These delimiters 
are shown in cyan to indicate that they do not have to be 
typed in. Movement through the display should automatically 
position the user at the next number to be filled in, 
skipping over any fixed field delimiters. 

An alternative suggestion is to retain values from 
a previous mission in these positions. This is feasible if 
many values do not change from launch to launch. Such 
items as LOX drain back and APU hold times and build-in 
hold times do not vary between launches. Therefore, some 
time could be saved when entering these parameters. With 
this method of entering data, the user should be able to 
retype only those positions within a field that need to be 
changed. For example, changing 0004/00 to 0007/00 should 
necessitate positioning the cursor on the 4 and retyping a 
7. Deciding on the method to use depends on the ability to 
support the correct interaction method and on the amount of 
data entry that the user could be spared. This method 
should be used only if the above interaction can be 
implemented and if the users feel comfortable using cursor 
positioning and retyping data. If this is not the case, 
then the first method should be used. 

2.5 What If Display 

The What If display allows the user to do some 
calculation on various times that are adjustable. The end 
result is to determine the maximum hold time remaining and 
the latest possible resume time. These calculations are 
based on COLA and contingency information in the launch 
window and the current countdown time and universal time. A 
possibility that exists within these calculations is 
resuming the count and holding for a certain amount of time 
later in the countdown. Figure 10 is the current version of 
the display. As the what if portion of the program is now 
implemented, three displays are used. Each display presents 
a different default plan. One display reflects the 
situation where no intermediate hold is used. The second 
display uses this intermediate hold situation. The thought 
behind revising these displays was to create one generic 
template that would encompass both scenarios as well as 
other scenarios. Two possible revisions were developed. 

The first is a textual display and the other a graphic 
version. 

Figure 11 presents the textual display. The times 
in the original display were presented in three columns, 
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universal time, countdown time, and interval time. The 
thought in revising the display was that the universal time 
and time intervals were most frequently used. Therefore, the 
countdown column was eliminated and the times were put into 
a middle column. The labels were put into two columns, one 
for evehts and the second for intervals. An up/down arrow 
beside of selected items indicates that the user may change 
the value of that item. The display allows for the user to 
choose the countdown time of the intermediate hold. The 
thought here is that by clicking on the selection arrows the 
times displayed would be the prescribed hold times, e.g., T- 
4M, T-2/55M, T-31S. The display includes start/end times 
for COLAS, but this information does not necessarily have to 
be included. As with the original display the events are 
ordered by time. 

The graphical version (Figure 12) lends itself to 
full direct manipulation but could function in the same 
manner as the textual display thus allowing implementation 
to proceed in stages. In a full direct manipulation mode 
the user could position events by dragging them to a 
position on the time line. The time value would be shown as 
the item is being moved. This allows a finer grain of 
control than the user has by dragging. The user could also 
click on the up/down arrows and the item would be positioned 
on the time line relative to the value selected for it. 
Repositioning would only take place after the user has 
pressed "enter" to indicate he has selected the desired 
value. A first implementation involving selection of values 
in this manner is advocated before implementing the direct 
manipulation interface. The benefit of this type of 
interface is that it allows the user to easily accomplish 
such tasks as "position T-0 close to the end of the window". 
Figure 13 shows how the user could be notified of 
constraints. 

In addition, a suggestion is to allow the user to 
setup several default plans, such as going to T-5M and 
holding for 5 minutes, prior to countdown and then selecting 
those plans by selecting the label. Input of these plans 
could be done via an input display that resembles the what 
if display. Figure 14 presents a prototype of an input 
display for default plans. These plans would be setup after 
the mission parameters have been input so that values for 
contingency time and launch window end would be Obtained 
from there. These values could then be changed in the 
default plan. For example, the NTD could construct a default 
plan that would necessitate asking for an extra five minutes 
on the end of the launch window. These plans could then be 
filed and later retrieved and applied to the current 
situation. 

Both the graphic and textual displays could be 
made available to the user and he could choose to display 
whichever is more appropriate to his style of decision 
making. 
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2.6 The Situation Assessment Display 

The situation assessment display contains 
information about the hold, the end of launch window, 
projected T-0 and other information and makes a 
recommendation to resume or not based upon this information. 
This recommendation also includes the rationale for the 
decision. This module is still being developed and hence 
the information that will be displayed is not yet fully 
specified. Recommendations for a display are shown in 
Figures 15 and 16. A template of information should be 
developed and those labels should always be displayed. 
Information that is not relevant to the present situation 
should not be filled in. Furthermore, information should be 
color coded so as to convey to the user the values in the 
template that are contributing to the seriousness of the 
situation. For example, if the projected T-0 is within a 
cola, that text would be displayed in red. The assessment 
information would display information about resumming in 
red. This would allow the user to quickly assess that it is 
unadvisable to pick up by using the red indicators in the 
resume field. If he wishes to read the text to obtain more 
information, he may do so. But he would be able to obtain 
initial information via position and color. Further work is 
being done on this module. Using this initial display will 
help in defining a set of variables that should be examined 
in any given situation. 


2.7 Data Collection 

The revisions that were made to the displays are 
based upon guidelines and theories (Dumas, 1988; Galitz, 
1989; Gilmore, Gertman, and Blackman, 1989; Helander, 1988; 
NASA, 1980; Smith and Mosier, 1986; Tullis, 1981) and upon 
data collected from the users. User data collection was 
difficult due to the workload on the NTD staff. Several 
launches were carried out during this research period and 
the NTDs were engaged in those as well as the simulation 
runs prior to each launch. However, the following procedure 
was carried out. The current system was used by an NTD 
during a simulation, his verbalizations were recorded on 
audio tape and notes were made about situations. The 
following items were noted during this process. Included is 
the resolution of each item. 

1. Qualitative information on window remaining 
should be easily accessable. 

Resolution: a graphical representation of 

projected T-0 within the window was incorporated into the 
clock section. 

2. COLA information is used for picking up at T- 

9M . 
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Resolution: this information is shown in launch 

window but consideration should be given to including the 
exact times on the labels. 

3. The point of no recycle should be included on 
the test parameter screen but does not need to be included 
with clock information. 

Resolution: this has been incorporated in the 

revised TMID and test paramater display. 

4. The major benefit of the what if display was 
envisioned to be taking the launch window end and working 
backwards from this. The time between launch window end and 
projected T-0 was seen to be dependent upon contingency time 
but not entirely. 

Resolution: The textual version of the revised 

what if display breaks this time interval into two parts: 
contingency time plus an additional time. Both should be 
capable of being changed to give a resulting interval. 

5. The clocks that are used differ in importance 
depending on the countdown time of the hold. At T-20M, the 
hold time remaining is most important. At T-9M the window 
remaining is important. At T-5M and under the hold time 
remaining (which increments at this point) is important. 

Resolution: consideration should be given to 

incorporating code to highlight the appropriate clocks at 
these times in order to direct the user's attention. 

6. When scrolling through the launch window it 
was easy for the user to loose his orientation. 

Resolution: moving the scroll bar to the right 

hand side of the display and making it more visible is 
important. The user can use this information to judge which 
portion of the display he is viewing. This has been 
incorporated into the revised TMID screen. 

7. A method of intially putting in parameters for 
each launch and for changing them during countdown should be 
provided. 

Resolution: A display has been prototyped for 

this purpose. - This feature is currently on the list of 
items to incorporate into LDSS. 

The second method of data collection involved an 
initial series of displays, namely the TMID screen, which 
were revised based upon informal comments and guidelines. 
Several situations were setup in order to obtain information 
about interpretations of specific decision making processes. 
These were shown to an NTD and discussed. Based upon this 
information, further revisions were made and again shown to 
the same NTD. This set of displays was distributed to other 
members of the NTD staff along with a questionnaire. This 
data yielded the following information: 

1. The clocks provided are sufficient. 

2. The LOX drain back clock in the firing room 
has been changed. This change will soon be incorporated 
into LDSS. 
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3 . Make sure that users understand which values 
in the clock section are static (Launch Window End) and 
which are computed. This needs further discussion with more 
members of the NTD staff. A color code could possibly be 
used here or the positioning could be changed. 

4. Reduced time marks are suficient. 

5. A finer grain of time (second resolution) was 
suggested. This is provided in two ways. First, when the 
LDSS runs the time shown is dynamic and updated on a second 
by second basis. Secondly, a new display has been developed 
which the user could switch to close to lift off which 
provides a ten second resolution. 

6. The color coding of the graphic display was 
deemed useful and clear. 

7. Color coding for the data values and time was 
questioned. The explanation of the color coding should be 
separated when presented to the user. For graphics, green 
represents safe, yellow cautionary and red represents a 
warning. For data values, cyan represents not yet relevant, 
green represents a valid, relevant data item, yellow 
represents a hold condition. Therefore, all clock values 
should appear either as cyan or green. The only exception 
is time to T-0 which should appear in yellow when there is a 
hold in the countdown. On the timeline of the TMID screen, 
the countdown times will be displayed in yellow when there 
is a hold. UT, CDT and event labels that have happened 
should change from cyan to green. 

8. GLS milestones should be labeled to refect 
times accurate to seconds. This has been incorporated on 
the revised TMID screen. 

9. Displaying latest resume time on TMID screen 
is useful. This was used in the decision making process. 
Therefore having this time available on the TMID screen will 
reduce movement between displays. 

10. A suggestion was made that it would be useful 
to have more information on time crital actions such as 
start recorders, APU Fuel ISO's, etc. This information will 
be displayed on a planned configuration management display. 

2.8 Complexity Issues 

In predicting a user's ability to easily obtain 
information from a display several items must be taken into 
account (Tullis, 1981) . The number of items in a group and 
the average size of the group is one determining factor in 
lowering search times. Results by Tullis suggest that the 
optimum range for alphanumeric displays is 40 groups 
averaging 4.9 degrees in size. Local density, how tightly 
packed a screen is, and layout complexity (the alignment) of 
the display also affects performance. Also important, these 
two issues affect subjective ratings by users. These issues 
were examined in the displays that are suggested for 
revision. The grouping of items and the size of the groups 
was considered somewhat in the revisions. This was mostly 
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in the clock information. Rather than keeping each clock as 
a separate entity, information was grouped according to 
functionality. The size of the groups was determined by the 
information presented and therefore, other rearrangements 
were limited. 

Complexity was analyzed for an original TMID and a 
revised TMID screen. As the information presented on these 
displays changes, various complexity measures will be 
obtained. For this analysis, two displays were chosen that 
represent one of the more complex displays. Using a easier 
calculation than the original Tullis calculation from 
information theory (Galitz, 1989) the following are summed: 
the number of data fields, the number of horizontal 
alignments (columns) and the number of vertical alignments 
(rows) . For the original TMID screen shown in Figure 17 
this produces a complexity score of 177. For the revised 
TMID screen, the complexity score is 153. This revision is 
a 13.6% reduction from the original. 

Density of a display is the proportion of 
characters displayed on the screen as opposed to the amount 
of blank screen. For density calculations, the screen was 
considered without its border. Dimensions were 70 by 28 
resulting in 1960 positions. For the original TMID screen, 
the density was calculated to be 52 percent. The density 
calculation for the revised screen was 40 percent. 

Although, this revision is still higher than the overall 
recommended level of 25 to 30 percent the fact that a 
portion of it is graphical should still result in a usable 
display. Further reduction is impossible as a principle 
adhered to in redesign was to reduce the amount of movement 
between displays. Therefore, this trade-off of higher 
density versus time to switch displays was made. 
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III. Trade-offs in Organizing Human-Computer Interaction 

Knowledge 


3.1. Introduction 

Currently, a large body of human-computer 
interaction knowledge exists. Most of this exists in the 
form of recommendations and guidelines. One of the 
difficulties in interface design is transferring this 
information to interface designers in such a manner that it 
can be incorporated into the design. Scapin (1991) examined 
the problems encountered when trying to implement human- 
computer interaction knowledge into the design. Scapin 
developed a framework for organizing this knowledge. This 
section discusses this framework, the problems that arise in 
using this framework, and a method for resolving one of the 
problems, namely, that of weighing trade-offs. 

3.2 Organization of HCI Data 

Scapin collected HCI data with the intent of 
organizing it into a database accessible by attributes. 
Attributes that were used for characterizing HCI 
recommendations were: criterion or criteria describing the 

rationale, the level (conceptual, semantic, syntactic, 
lexical) that describes the outcome and rationale, and the 
type of interface object to which the recommendation 
applies. Several conclusions were drawn by Scapin during 
this process. He found that a recommendation in the 
literature could lead to more than one recommendation in 
terms of implementation. Many recommentations were too 
vague and needed elaboration in order to be useful in 
implmentation. Additionally, different authors used 
different wording for the same recommendations necessitating 
translation to a stable vocabulary. 

Scapin proposed a generic deciphering framework of 

the form: 

if (a premise) ... (using Criteria)... then (a Conclusion) 

Premises are defined to be of four types: 
type/characteristics of user 
type of user task 

design activity of the interface for which 
the knowledge is being used, 
context or the particular state of the user 

interface . 

The criteria used are: 

Compatability with past habits and skills of the 
user, between input and output, between noncomputerized 
support and software, and with interface standards. 
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Consistency in location, format, syntax and naming 
conventions. 

User Workload with respect to minimizing mental 
and physical effort required. 

Adaptability or the capability of the interface to 
adapt to various user actions. 

User Explicit Control allows the user to control 
the dialogue and to explicitly enter information. 

significance of codes or use of labels, codes, and 
abbreviations that are meaningful to the user. 

Guidance so that the user can identify what he can 
do next. This includes feedback and clarity in display. 

Error Managment is the attempt to prevent or avoid 
errors and to give meaningful feedback when errors do occur. 

Conclusions can be of two types: design activity which 

represents a conclusion or specific activity or an action 
item which is the type of activity required to apply a rule. 

Scapin notes intrinsic and usage problems involved 
in applying human factors knowledge. Intrinsic problems 
consist of recommendations that are incomplete, 
recommendations that are too general to be useful and 
recommendations that lack robustness (apply only in limited 
contexts) . Usage problems are accessing recommendations, 
making trade-offs in deciding which recommendations to 
apply, and the varying degree of detail of the 
recommendations . 

3.3 A Method for Prioritizing Trade-offs 

Recommendations do not come organized in a 
hierarchy. Therefore, the designer will often be faced with 
several approaches, each giving priority to different 
recommendations and resulting in different solutions. In 
order to balance trade-off decisions, several issues arise. 
The first is what factors should be used to determine 
weights for guidelines. The second issue is how to ensure 
that these trade-off decisions are made consistently. The 
method presented here builds on Scapin’ s work. As discussed 
in section 3.2, Scapin presented eight criteria and 
suggested the types of guidelines that pertain to each. In 
order to prioritize decision making, these criteria are used 
and weighted according to some known user and task 
information. During the evaluation of LDSS, the following 
information was used to prioritize guidelines: type of 

user, attention time, timing of task, critical aspect of 
task, and critical aspect of software. Each of these 
categories can have several different values which would 
dictate prioritizing different criteria and hence, 
guidelines. The following discussion is a suggested set of 
values and emphasized criteria. 

Type of user refers to the novice, casual, expert 
classification. For a novice user the primary criteria 
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would be guidance. Error management, compatability with 
past habits, significance in codes, consistency workload and 
explicit control would be secondary criteria. A casual user 
would dictate the same criteria but consistency and workload 
would become primary criteria along with guidance, error 
management, and compatability. Expert users would be more 
concerned with adaptability than any of the other criteria. 

The attention time of the user is also an 
important factor in determining trade-offs. What else 
competes for the user's attention while dealing with the 
software? Suggested values range from undivided attention 
to moderate attention to little attention. In the case of 
little attention, where the user is attending to many other 
tasks and using the software primarily for support, issues 
of consistency, guidance, workload and significance of code 
become the primary criteria. Compatability becomes a 
secondary concern. In the case of moderate attention the 
same criteria are important but could be considered 
secondary concerns rather than primary concerns. If the 
user has undivided attention to devote to the software then 
adaptability could be classified as a primary concern. The 
user has time to discover various aspects of the system and 
is able to choose a method of performing a task that is more 
suited to his individual style. 

Task considerations should include whether the 
task is a real-time or nonreal-time task. That is, is the 
software supporting a shuttle launch or is the software an 
income tax spreadsheet? This consideration is similar to 
the attention of the user consideration in that the primary 
criteria for real-time tasks should be the same as for 
limited attention: workload, guidance and consistency. 

Nonreal-time tasks place adaptability as a primary concern. 
The critical issue of the task involves the importance of 
the software to the task. That is, can the task be 
completed without use of the software? Critical software 
would dictate that error management be a prime concern with 
guidance as a secondary concern. A second concern is the 
nature of the task. Software that aids in landing aircraft 
would be deemed more critical than software for producing 
slides. Criteria important for this type of critical 
software would be: significance of codes, guidance, and 

consistency. The emphasis is placed on the ability to 
correctly interpret information presented. 

The method for prioritizing criteria and hence, 
guidelines, involves collecting this information concerning 
users and tasks. Then individual criterion is given two 
points for each time it appears as a primary concern and one 
point each time it appears as a secondary concern. The 
criteria with the highest scores should then be used as the 
deciding factor in trade-off decisions. Guidelines that 
support those high scoring criteria should be utilized over 
guidelines supporting criteria receiving lower scores. 

The method used here needs further refinement to 
ensure that it correctly addresses all values for suggested 
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categories. Nonetheless, this method was used quite 
successfully in making consistent trade-off decisions during 
revision of the LDSS interface. In this case, the users 
were casual, the attention of the users limited, the task 
was real-time, and critical but the software is not critical 
for success of the task. Using this scheme an interface was 
produced in which priority was given to guidelines which 
enhance the users* ability to discern information from the 
screen and to minimize the amount of interaction required by 
the user. Consistency and guidance were the highest ranking 
criteria followed by work load and significance of codes. 
Little effort was put into making the system flexible. As 
the amount of interaction was limited, little effort was put 
into error management. In order to further refine this 
method and to determine its robustness, it will be necessary 
to evaluate more interfaces which have different tasks and 
users. A successful method would be capable of producing 
usable interfaces for a wide range of user and task 
characteristics. 
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IV. CONCLUSIONS 

Suggested revisions for the LDSS interface have 
been developed using a combination of empirical information 
and application of human-computer interaction knowledge. 

The process of developing these revisions was tracked and 
led to a method for prioritizing criteria for use in trade- 
off decisions. As LDSS will now be field tested in the KSC 
firing room, the actual usability of the interface can be 
assessed. Due to the nature of the ANTD/NTD job, 
information concerning the use of the interface will have to 
be collected in a nonintrusive fashion. As the use of LDSS 
is optional and will require a change in the ANTD/NTD 
procedures during countdown, the initial and sustained use 
of LDSS will be a major indication of the usability of the 
system. Additionally, information must be collected after 
use of the system. This information should discriminated 
between missing information, misinterpreted information and 
mistrusted information. Audio tapes of countdown 
activities, especially S0044 simulations, along with 
observations by the LDSS staff can be used to obtain this 
information. In addition, post countdown interviews with 
the ANTD and NTD are very valuable. Any changes that are 
made to LDSS as a result of these observations and 
interviews should be documented in the form of guidelines. 
New software development will benefit in the form of time 
savings and monetary savings from use of these guidelines. 
Utimately, the users of these software tools will benefit 
from the increased usability of newly developed tools. 
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Figure 4: Revised TMID, T-20M, Unable to Resume 
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Figure 5: TMID with fine grain resolution 
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Figure 7: Dynamic Overview Display 
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Figure 9: Revised Test Parameters Screen 
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Figure 10: Original What If Display 
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Figure ll: Revised What If Display, Textual Version 
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Figure 12: 


Revised What If Display, Graphical Version 
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TIME 000/00 


0000/00 


RESUME 
0000/00 $ 


COLA 

X X 


PROJECTED 


0000/00 


LATEST RESUME 
TIME 0000/00 S 


TIME IN HOLD 
0000/00 * 1 


DEFAULT PLANS 
PLAN A 0 
PLAN B 0 


MAN HOLD 
TIME REM 
0000/00 


PLAN C 0 
PLAN D 0 


t 

LU END 


0000/00 * 0000/00 $ 


CONTINGENCY 
0000/00 $ 



Figure 13: Revised What If Display, Graphical showing Constraints 


UT 

005:1028/00 

CDT 

-00:0003/00 HOLDING 

SELECT UALUES FOR 

DEFAULT PLANS. 

THEN SELECT LABEL 

FOR PLAN. 



EUENTS 


INTERUALS 

INTERMEDIATE HOLD 

0 HHMM/SS 


T-00 * 

t HHMM/SS 

HOLD TIME 


$ HHMM/SS 

CONTINGENCY 

IW END 

$ HHMM/SS 


PLAN A 0 

PLAN § 

PLAN C 0 


TIME TO T-0 
0010/00 
PROJECTED T-0 
005:1038/00 


UIND0U REM 

0024/00 

LU END 
005:1052/00 

HOLD TIME REM 
0001/00 
TIME IN HOLD 
0003/00 

TIME TO NO START 
0002/00 

LDBT ELAPSED 
HHMM/SS 
APU HOLD TIME 
HHMM/SS 

MAX HOLD TIME 
0015/00 
LATEST RESUME 
005:1043/00 
TMUI 0 TMSA 0 


Figure 14: What If Default Input 
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UT 

005:1035/15 

CDT 

-05:1009/00 

HOLDING 

SITUATION 

TINE: 

T-9N 


HOLD: 

EXTENDED 


LAUNCH WINDOW: 

LONG 


CONTINGENCY: 

NONE 


PROJECTED T-0: 

WITHIN CONTINGENCY OF 

A COLA 

ASSESSMENT 

RESUNE: UNADUISABLE 


WHY: WILL NOT 

TO COLA 

HAUE FULL CONTINGENCY 

TINE PRIOR 


TIME T0 T-0 
HHOO/SS 
PROJECTED T-0 
DDDiHHHfl/55 


UIIMD0U REtl 

HHnn/ss 

LAUNCH WIN STOP 
DDD s HHNN/SS 


HOLD TIME REM 
HHnn/ss 
TINE IN HOLD 
HHnn/ss 

TIME TO NO START 
HHnn/ss 


LOX DRAIN BACK 
HHNN/SS 

CONTINGENCY TINE 
HHNN/SS 


MAX HOLD TINE 
HHNN/SS 
LATEST RESUNE 
DDD : HHNN/SS 
TNWI 0 TNSA 0 


Figure 15: Revised Situation Assessment 


UT 

1005 : 1028/00 


CDT 

• 00 : 0009/00 


HOLDING 


SITUATION 


TINE: 

HOLD: 

LAUNCH WINDOW: 
NAX HOLD TINE: 
CONTINGENCY: • 
PROJECTED T-0: 


T-9N 

EXTERNAL 

LONG 

LONG 

NO CONSTRAINTS UNTIL 0000/00 


A5SESSNENT 

RESUNE: ADUISABLE UNTIL 0000/00 

WHY: NO CONSTRAINTS 


TINE TO T-0 
0010/00 
PROJECTED T-0 
005:1038/00 




WINDOW REN 

0024/00 
LAUNCH WIN END 
005:1052/00 


HOLD TINE REN 
0001/00 
TINE IN HOLD 
0008/00 

TINE TO NO START 
0002/00 


LDBT ELAPSED 
0000/00 

CONTINGENCY TINE 
0000/00 


MAX HOLD TINE 
0015/00 
LATEST RESUNE 
005:1043/00 
TNWI 0 TNSA 0 


Figure 16: Revised Situation Assessment, Display 2 
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